Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ien/ien-191

Text File | 1988-12-01 | 28KB | 639 lines

Internet Experiment Note: 191                                C. Sunshine
                                                                D. Cohen
                                                               J. Postel
                                                                     ISI
                                                               July 1981

                       Comments on Rosen's Memos


INTRODUCTION

   This memo comments on recent IEN's by Eric Rosen of BBN (numbers 182,
   183, 184, 187, 188, 189) [1,2,3,4,5,6].  We think these notes raise
   some important and interesting issues which require further
   discussion.  In the following we focus on the points of disagreement
   (but don't assume that we agree with something simply because we
   don't mention it here).  After a brief general comment we discuss
   each note in turn.

   There are some good points raised in this series.  Unfortunately the
   presentation is both verbose and incomplete.  There is nothing wrong
   with taking a certain aspect of a topic and exploring it at length,
   but these memos seemingly present all available alternatives and
   select the "best" for further development.  Our concern is that, in
   fact, not all alternatives are studied, and not all evaluation
   criteria are given the proper weight in selecting the "best"
   alternative.  A minor problem is the informality of the references.
   It is unclear exactly which earlier memos, reports, and papers the
   author has in mind in some of the discussion, and it is unclear if
   the author is aware of some very relevant material.  In some sections
   it appears that the author is unfamiliar with much of the relevant
   material, and hence fails to include important points in his
   presentation.

IEN 182

   This note on "Issues in Buffer Management" is, in the main, a
   description of buffer management in the ARPANET IMPs.  This is quite
   useful and should be food for thought for gateway designers and
   implementers since gateways may have some of the same constraints and
   concerns in buffer management as IMPs.  However, the differences that
   do exist in the goals for gateways and IMPs are not taken into
   account, so the policies adopted for IMPs are not necessarily
   appropriate for gateways.  Differences in the level of reliability of
   delivery, and the end-to-end virtual circuit vs. the datagram style
   of service can lead to substantial differences in the requirements
   for buffer management.

   This is a useful memo in that it exposes a good deal about the buffer
   management polices used in the ARPANET IMPs, information that is not
   easily found elsewhere.  But it is contains some weakly supported



Sunshine & Cohen & Postel                                       Page [1]



July 1981                                                        IEN 191
Comments on Rosen's Memos



   overly broad conclusions that seem to ignore and sometimes contradict
   existing results in this area.

IEN 183

   This memo presents a proposal for a logical addressing mechanism in
   the ARPANET, and includes a good deal of discussion of alternatives.
   Interested readers should see earlier IEN's on the subject from MIT,
   ISI, and Xerox, plus the classic paper by Shoch, and recent work on
   "naming authorities" at Xerox, which the author fails to credit or
   reference [7,8,9].

   We prefer the more commonly used term "name" to the phrase "logical
   address" which the author uses.

   The key proposal is to include a name-to-address lookup function in
   the source switches of a network so that the "user" will not have to
   supply ("physical") addresses.  This seems a worthwhile goal, but the
   meaning of "user" seems confused between (1) people or application
   programs using the network, and (2) network access software (such as
   NCP or TCP) supporting (1) in the hosts.  The author seems oblivious
   of this distinction.

   Everyone agrees that category (1) "users" should be able to use
   names.  Of course, most ARPANET hosts' category (2) software already
   provides this function (the host table) for category (1) "users".
   The proper discussion should be whether this function is best located
   in the switches, or in the network support software of the hosts, but
   this is not explicitly addressed by the author.

   The author presents a reasonable approach to implementing a name
   lookup function without requiring broadcast of dynamic changes to all
   participants.  A basic table of all potentially usable addresses for
   each name must be distributed to all parties (the "authorized"
   table), but this is expected to change relatively slowly.  Entries in
   this table are assumed usable ("effective") until an explicit
   exception message ("destination not accessable") results from using
   them.  The unusable markings are reset after a time interval.

   We agree that this is a worthwhile proposal, but the placement of
   this function in the hosts, the switches, or a separate name lookup
   service needs further discussion.  Since most hosts are already
   performing this function as noted above, it is clearly within their
   capabilities.  An advantage of placement in the switches seems to be
   prevention of "spoofing" since hosts can only send/receive messages
   from/for a specified name if that name is "authorized" for the



Page [2]                                       Sunshine & Cohen & Postel



IEN 191                                                        July 1981
                                               Comments on Rosen's Memos



   addresses they are physically attached to.  Of course this requires
   source and destination switches to check messages in a "trusted"
   fashion.

   There is a small inconsistency in the author's discussion of
   source-only vs. intermediate ("tandem") node name lookup.  At the top
   of page 11, it is stated that the tandem nodes will be "no more
   likely" than the source node to have new information during a
   transient update period.  However, on page 12-13, it is pointed out
   (correctly) that tandem nodes likely WILL produce a "better route
   selection ... if delay changes or topology changes take place while a
   packet is in transit."

   There will be substantial modification needed to the host software in
   order to implement this scheme.  It is proposed (we think) that both
   the current scheme and the logical address scheme be available at the
   same time.  The details of the logical address are not very clear,
   but a 16-bit logical address is suggested, which would require a
   character string to number lookup in the hosts to make it convenient.

IEN 184

   This memo claims that the previous work on the Internet is deficient
   due to reliance on an inadequate model of the structure of the
   Internet.  IEN 184 claims to present a new model of the Internet that
   does provide a basis for future work.

   The proposed model of internetwork operation views the gateways more
   explicitly as switching nodes, with the hosts attached to these
   nodes.  In particular, each host is multi-hommed on all the gateways
   on the same network as the host.

   There is some merit to this model and the questions it raises, but
   the author is not the first to think of this viewpoint (see for
   example IEN-135 [10]).  There are also some problems with this model
   that the author seems unaware of.

   This new model might be acceptable if one wanted to build a super
   ARPANET based solely on lines and super-IMPs, but if one is planning
   to include other technologies such as broadcast satellite and
   broadcast local networks, the  proposed model has serious flaws.

   For example, two hosts on the same net may still wish to use Internet
   protocols to communicate.  In the author's model, they would have to
   do so by going through an intermediate gateway on their net, since by
   definition, no hosts can communicate directly over a "Pathway" with



Sunshine & Cohen & Postel                                       Page [3]



July 1981                                                        IEN 191
Comments on Rosen's Memos



   no intervening "Switch."  This is clearly inefficient in the intranet
   case, and one way in which it differs from the ARPANET.  This would
   also be true in many single broadcast nets where there are no
   intervening switches between hosts even at the single network level
   of "Network Structure."

   This memo fails to consider the impact on the host systems.  Host
   will be designed to use a common approach to communication with other
   hosts whether they be across the room or across the world.  With the
   existing model and Internet Protocol, the same procedures and formats
   can be used between hosts on the same network and between hosts many
   networks apart (though different performance parameters may be
   necessary).

   The model developed in the Internet Working Group and described by
   Cerf (IEN-48 [11]) continues to be the most reasonable basis for
   developing the Internet.

IEN 187

   This memo assumes the model (of IEN 184) of hosts always sending and
   receiving internet traffic via an "Internet Switch".  It goes on to
   describe the interactions of a host and an internet switch, and then
   criticizes the existing Internet Protocol for not being a perfect
   host-switch interface protocol.

   We cannot possibly take on all of the topics and "lessons" presented,
   but Section 2.4 of IEN-187 on fragmentation provides a good example
   of what is wrong with these reports.  Again, the author seems unaware
   of previous important work on this subject, for example IEN-20 by
   Shoch (expanded and published in Computer Networks in 1979) [13], or
   the paper by Sunshine on interconnection of networks published in
   Computer Networks in 1977 [14].  If the author had read these, he
   might have avoided several serious deficiencies in his presentation:

      1. After a long discussion of the evils of final destination (or
      internet) fragmentation, the author reveals his preferred approach
      of hop-by-hop (or intranet) fragmentation as if he invented the
      idea.

      2. There is an important goal that internet fragmentation
      supports, but intranet fragmentation does not: independent and
      possibly different routing of each fragment through different exit
      gateways from a "small packet" net (and subsequently).  The author
      fails to consider this point.




Page [4]                                       Sunshine & Cohen & Postel



IEN 191                                                        July 1981
                                               Comments on Rosen's Memos



      3. In presenting scenarios (page 58) showing the evils of internet
      fragmentation, the author omits the important scenario of several
      small packet nets in a row, where repeated intranet fragmentation
      is just the WRONG thing to do.

      4. Packets with the Don't Fragment flag on are not "simply lost in
      transit" (page 53) if they cannot be forwarded without
      fragmentation.  Specific error packets are returned to the source
      host, which may try to resend smaller packets.

      5. After all his discussion, the author admits in the final
      paragraph that destination host fragmentation is necessary anyway
      if the final network gets too large a packet.  The author claims
      this will be necessary only for hosts on nets with "unusually
      small" maximum packet sizes, but in fact it will be necessary on
      all nets with less than the maximum maximum packet size of any net
      in the system if they wish to receive packets from the largest
      packet size nets.

   The net effect of this sort of incomplete presentation is a step
   backward from the current imperfect level of understanding of this
   important issue.

   The author also attacks the Type of Service (TOS), Time to Live
   (TTL), Source Routing (SR), Flow Control (FC), and Fault Isolation
   (FI) features of IP and ICMP.

   On Type of Service the author tells us for ten pages all the bad
   things about the Internet Protocol provision for TOS, while agreeing
   it is an important concept, but has nothing different to offer,
   except some vague notion that service catagories should correspond
   more closely to application types.

   On Time to Live the author complains that there is an inconsistency
   since the TTL is stated to be in seconds, and that the gateways must
   decrement the TTL by one, and that the gateways are expected to
   process datagrams faster than one a second.  If one assumes that the
   intention is to guarantee that datagrams stay alive as long as the
   TTL, he is right.  But the intention is really to guarantee that they
   disappear before TTL.  So TTL is an upper bound on how long the
   datagram may exist.  Most reliable transport protocols assume a
   maximum datagram lifetime (sometimes unknowningly) for the correct
   operation of their reliability procedures [15].

   On Source Routing the author suggests that this feature exists due
   only to problems with existing routing procedures and for



Sunshine & Cohen & Postel                                       Page [5]



July 1981                                                        IEN 191
Comments on Rosen's Memos



   experiments, and that any really adequate routing procedure in the
   gateways will eliminate the need for source routing in normal
   operations.  We suggest that the Internet will be a much more dynamic
   environment than the author has yet imagined and that source routing
   will be essential to reach through the Internet to local environments
   not fully integrated into the main Internet routing world.

   On Flow Control and Fault Isolation the author indicates that the
   current mechanisms are inadequate, but does not suggest workable
   alternatives.  On FC the ICMP "Source Quench" message is cited as a
   case of "choke packet" flow control which the author does not believe
   in (page 64).  Earlier (page 63) the author complains that "source
   quench" is only advisory, and later (page 66) the author makes vague
   suggestions that a better flow control scheme would use advisory
   messages to suggest that datagrams had been discarded (exactly what
   source quench does).

   All in all this memo comes across as an attack on the Internet
   Protocol, with few suggestions for improvement.  But it is based on
   an assumption:  that the Internet Protocol is a host-switch access
   protocol.  This assumption requires further discussion.

IEN 188

   This memo describes logical addressing in the Internet, primarily by
   recasting the method of IEN 183 in generalized terms.  There are a
   number of inaccuracies and omissions in the discussion.  One serious
   limitation is failure to consider the case of hosts sending Internet
   datagrams to each other directly on a single net as discussed above.

   On page 4 (middle), the author correctly states that IP addresses are
   hierarchical, but incorrectly states that their second component is
   necessarily a "physical address."  In fact, it may be a name or
   "logical address" in networks that provide that capability (but must
   be carried in 24 bits).

   On page 7, the author proposes using a "unique name which is
   meaningful at each level of internet hierarchy."  This seems to be a
   strong violation of layering, and as the author admits, would require
   the switches in every constituent network to "understand" and be able
   to lookup the names, probably an intolerable demand on individual
   network autonomy.

   On page 34, the author's claim that hierarchical addressing requires
   less table space than flat addressing is false.  His justification is
   incomprehensible to us, particularly since he has just finished



Page [6]                                       Sunshine & Cohen & Postel



IEN 191                                                        July 1981
                                               Comments on Rosen's Memos



   proposing an "area" addressing scheme similar to hierarchical schemes
   in order to reduce table sizes!

   In the detailed model of operation given in Section 3.4, an important
   step is omitted when the first sentence states, "Let's assume that a
   source Host has given a message to a source Switch ..."  How does the
   source host pick the source switch?  In fact, it must pick both a
   network level (e.g., IMP) and internet level (gateway) switch,
   assuming it is multi-homed, which at least at the internet level is
   quite likely.  In order to make this selection, the host will have to
   have a table giving the best switch (at each level) for each possible
   destination name.  But these are precisely the sort of tables the
   author's scheme is meant to avoid having in the hosts.  In light of
   the comment above about hosts talking to each other directly on the
   same net, the hosts must at least know the names and addresses of
   every other host on their own net.

   The treatment of mobile hosts is quite brief and offers no
   improvement over previously proposed solutions.

IEN 189

   This memo discusses routing in the Internet, and proposes that the
   existing gateway routing procedure be replaced by the SFP procedure
   now used in the ARPANET.  This is surely a useful suggestion.  The
   note does however raise a number of issues in its examples of routing
   problems that indicate an incomplete understanding of the whole area.

   The note proposes a "gateway discovery protocol" that could be
   provided by individual nets.  This idea seems worthwhile, although it
   is not clear how many individual nets would be willing to make such
   additions.  We should like to point out that it is also possible to
   perform this function directly among gateways in networks which
   support broadcast or group addressing.

   The discussion of routing alternatives makes generally sound if
   qualitative conclusions, but a few details are confused.  The
   discussion of throughput performance on page 41 assumes TCP will
   operate with a small enough window over a high delay path so that
   throughput is reduced, but this is precisely the situation in which
   proper "tuning" requires a large window, which would allow high
   throughput.

   The analogy with "whole picture" algorithms on pages 44-45 fails to
   mention that in the whole picture scenario, each person would have to
   get a piece of paper 100 times bigger than with the local scheme, and



Sunshine & Cohen & Postel                                       Page [7]



July 1981                                                        IEN 191
Comments on Rosen's Memos



   hence this approach has an information distribution requirement that
   is much higher.

   This memo contains several informal citations that could be usefully
   spelled out for the IEN audience.  The author mentions algorithms by
   Gallager (page 17), Dijkstra (page 20), and Floyd (page 20), all
   without references.  It is safe to say that any list of references
   containing only the author and his coworkers (as consistently done in
   this series) cannot be adequate.

   One particular example provokes the following response:

      Please replace the second paragraph of page 49 of IEN-189 with the
      following paragraph:

         "In fact the situation could be even worse.  If Switches in
         Boston know nothing about what happening inside the building on
         4676 Admiralty Way then data for the North section of the 11th
         floor which arrives at the South section of the 11th floor is
         then sent back from the South section to Boston for alternate
         routing will just loop back to the South section.  The data
         will be stuck in an infinite loop, never reaching its
         destination.  In IEN 179 [12] Danny Cohen proposed a regional
         scheme like this, apparently not realizing that it suffers from
         loops.  His proposal also includes a form of hierarchical
         addressing which is closely bound up with routing, so that a
         Switch is Boston might not even be able to distinguish data for
         the South section from data for the North section.  That is, in
         Cohen's scheme, data for the South section and data for the
         North section would be indistinguishable at the Boston
         Switches; all such data would appear to be addressed to the
         South section.  Only the Switches at the South section would
         look further down the address hierarchy to determine whether
         the data needs further forwarding to the North section.  Any
         such scheme is hopelessly loop-prone, except in a Network
         Structure whose connectivity is extraordinarily rich, much more
         so than the Catenet's will ever be."

      Since the above suggestion was merely to follow the routing
      strategy used by the phone companies, TELENET and others, you
      should warn them immediately about this hopelessly loop-prone
      situation.

      I believe that if the Boston Switch has ALL the information about
      EVERYthing, EVERYwhere it would be in position to make better
      decisions, ALWAYS, especially if that information is updated with



Page [8]                                       Sunshine & Cohen & Postel



IEN 191                                                        July 1981
                                               Comments on Rosen's Memos



      absolutely ZERO time delay.  If this information is absolutely
      free (in terms of communication, storage and processing) it may be
      dumb not to make every Switch always know everything about
      everything, down to (or "up to"?) the finest granularity
      (location? site? process? file? register? bit?). However, if this
      is not absolutely free, some compromises may have to take place.

      Oh, one point which I did not quite follow: why if the
      Nevada/California lines are broken forever, Boston is never told
      about it - as described by you?  By the way, what made you
      understand that the "The Switch at Nevada would look further down
      the address hierarchy to determine whether the data needs further
      forwarding to California" ?

      I highly recommend that you get hold of any telephone directory
      and read the area-codes tables.  This may help you understanding
      that the California area codes are neither above, nor below, nor
      further on any hierarchy than the Nevada ones, and vice versa.

      This is a very subtle point which may escape the casual reader.
      Mastering this idea may help you understand what IEN-179 is all
      about. In short, IEN-179 is not an attempt to describe the ideas
      which you have in mind by using the telephone scenario, but an
      attempt (which obviously failed, at least in your case) to
      introduced old well-proven ideas from other communication arenas
      into ours.

SUMMARY

   In summary we are glad to have this information and these opinions
   presented for discussion in the Internet Working Group, and we hope
   that others will speak up with their opinions too.  We are concerned
   that too many will be so overwhelmed by the wide ranging arguments to
   notice that some important considerations were not mentioned.

   We especially want to make clear that a fundamentally different model
   of the Internet architecture is proposed by Rosen, and that we have
   serious reservations about aspects of that model.











Sunshine & Cohen & Postel                                       Page [9]



July 1981                                                        IEN 191
Comments on Rosen's Memos



REFERENCES

   [1]  Rosen, E., "Issues in Buffer Management", IEN 182, Bolt Beranek
        and Newman, May 1981.

   [2]  Rosen, E., "Logical Addressing", IEN 183, Bolt Beranek and
        Newman, May 1981.

   [3]  Rosen, E., "Issues in Internetting Part 1: Modelling the
        Internet", IEN 184, Bolt Beranek and Newman, May 1981.

   [4]  Rosen, E., "Issues in Internetting Part 2: Accessing the
        Internet", IEN 187, Bolt Beranek and Newman, June 1981.

   [5]  Rosen, E., "Issues in Internetting Part 3: Addressing", IEN 188,
        Bolt Beranek and Newman, June 1981.

   [6]  Rosen, E., "Issues in Internetting Part 4: Routing", IEN 189,
        Bolt Beranek and Newman, June 1981.

   [7]  Clark, D., "A Proposal for Addressing and Routing in the
        Internet", IEN 46, MIT/Laboratory for Computer Science, June
        1978.

   [8]  Cerf, V., "Internet Addressing and Naming in a Tactical
        Environment", IEN 110, Information Processing Techniques Office,
        Defense Advanced Research Projects Agency, August 1979.

   [9]  Shoch, J., "Inter-Network Naming, Addressing, and Routing",
        Proceedings 17th IEEE Computer Society International Conference,
        pp72-79, September 1978.

   [10] Sunshine, C., "Addressing Mobile Hosts in the ARPA Internet
        Environment", IEN 135, USC/Information Sciences Institute, March
        1980.

   [11] Cerf, V., "The Catenet Model for Internetworking", IEN 48,
        Information Processing Techniques Office, Defense Advanced
        Research Projects Agency, July 1978.

   [12] Cohen, D., "Addressing and Routing", IEN 179, USC/Information
        Sciences Institute, March 1981.

   [13]  Shoch, J., "Packet Fragmentation in Inter-Network Protocols",
        Computer Networks, V.3, N.1, pp3-8, February 1979.




Page [10]                                      Sunshine & Cohen & Postel



IEN 191                                                        July 1981
                                               Comments on Rosen's Memos



   [14]  Sunshine, C., "Interconnection of Computer Networks", Computer
        Networks, V.1, N.3, pp175-195, January 1977.

   [15]  Watson, R., "Timer-Based Mechanisms in Reliable Transport
        Protocol Connection Management", Computer Networks, V.5, N.1,
        pp47-56, February 1981.











































Sunshine & Cohen & Postel                                      Page [11]